fix(queue): surface a finding when capture-unobtainable degrades the screenshot-table gate - #10256

• src/queue/processors.ts:8944-8970 nests three sequential early-return/continue conditions (violated, degraded, non-advisory) inside one try block — a short comment above the degraded branch stating the fallthrough contract would help future readers avoid re-introducing the original bug.
• The captureUnobtainable comment in the call site at src/queue/processors.ts:12332 asserts it 'cannot disagree' with runAgentMaintenancePlanAndExecute's own expression, but that call site's expression itself is not visible in this diff, so this claim can't be independently verified from what's shown here.
• test/unit/screenshot-table-gate.test.ts's close/block wiring tests assert `screenshotTableEvidenceUnresolved: false` is hardcoded rather than derived from the real caller's degraded-state computation, so they pin the planner's response to a claimed fact rather than proving the real caller actually produces that fact.
• Consider extracting the `result.enforcementDegradedReason !== undefined` branch's early-return-with-push into a small named helper shared with the non-degraded advisory branch below it, since both construct near-identical AdvisoryFinding objects with only `detail`/`title` differing.
• The `let files = args.files; if (files === null) { ... }` rewrite (replacing `??`) is explained as a coverage workaround in the comment — worth double-checking with Codecov after merge that it actually resolves the phantom-0-hit issue described, since the two forms are logically equivalent for a non-optional `X | null` field.
• Readiness score is below the configured threshold — Use the readiness panel as advisory maintainer context; the score does not block this PR.

Addressed
The diff threads captureUnobtainable into maybeAddScreenshotTableAdvisoryFinding and its evaluateScreenshotTableGate call, changes the early-return to only skip on non-advisory action when not degraded, appends a warning-severity finding combining the gate's reason and CAPTURE_UNOBTAINABLE_REASON on the degraded path regardless of action, and updates the call site at the visual-capture check to pa

• Author: bitfathers94
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: TypeScript
• Official Gittensor activity: 140 PR(s), 3 issue(s).
• PR-specific overlap: none found.

• Start here: Add a concise scope and risk note.
• Then work through the remaining 2 steps in the Signals table above.

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

Ask LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @loopover ask <question> answers contribution-quality Q&A with source citations and freshness.
• @loopover chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @loopover mention with a real question is routed to the closest matching read-only command automatically — no exact syntax required.

Full command reference: https://loopover.ai/docs/loopover-commands

🧪 Experimental — new and may change.